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Abstract. Reactive applications 

( rapps ) are of interest because of 
the explosion of mobile, tablet and 
web-based platforms. The complexity 
and proliferation of implementation 
technologies makes it attractive to use 
model-driven techniques to develop 
rapp systems. This article proposes 
a domain specific language for rapps 
consisting of stereotyped class models 
for the structure of the application 
and state machine models for the 
application behaviour. The models 
are given a semantics in terms of a 
transformation to a calculus called 
Widget. The languages are introduced 
using an example application for mobile 
phones. 

1 Introduction 

Harel and Pneuli [?] define reactive applica¬ 
tions (rapps) as systems that receive events 
from their environment and must react ac¬ 
cordingly. Reactive systems are of increasing 
interest partly because of the recent explosion 
in number and diversity of mobile and tablet 
platforms. Together with web-applications, 
mobile and tablet apps operate by reacting to 
user input and changes to the platform con¬ 
text. 

There are some characteristic features to 
this family of applications: they are mainly 
driven by events that originate from the user 
or the application context; many applications 
have user-interfaces that consist of simple hi¬ 
erarchically organized elements such as text, 
buttons, input fields etc.; often applications 


can be described in terms of a machine whose 
states are described in terms of a tree of user- 
interface elements and associated event han¬ 
dlers, and whose transitions occur in response 
to events. Although the applications are es¬ 
sentially quite simple, the development com¬ 
plexity arises because of the significant differ¬ 
ences between multiple target platforms. 

1.1 Model Driven Development 

Model Driven Development (MDD) [?] is an 
approach to Software Engineering that uses 
models to abstract away from implementation 
details and to use code generation or model 
execution to produce a complete or partial 
system. By abstracting away from the imple¬ 
mentation technology, the system definition 
can target different platforms and it is ar¬ 
gued that the system becomes easier to main¬ 
tain [?]. Model Driven Architecture (MDA) 
is an approach that uses UML to perform 
MDD and involves UML being used to con¬ 
struct Platform Independent Models (PIMs) 
and Platform Specific Models (PSMs) and to 
model transformations between them. MDD 
is of interest to rapp development because of 
the diversity and complexity of target plat¬ 
forms; an application can be developed as a 
single model and then transformed to multi¬ 
ple implementation technologies using general 
purpose transformations. 

Although there are characteristic rapp fea¬ 
tures, implementation technologies remain 
general purpose. Android and iPhone appli¬ 
cations are developed using frameworks where 
application classes extend platform specific li¬ 
braries that hide the application logic. MDD 
approaches seek to address these issues by ab¬ 
stracting away from the implementation de¬ 
tails; however, current MDD approaches that 
are relevant to rapp are often incomplete and 
do not support reasoning about the applica¬ 
tion. 

This article describes work that aims to 
provide a precisely defined framework for 
model-driven rapp in terms of a modelling lan- 



guage and an associated calculus. Like other 
model-driven approaches, the structure and 
outline behaviour of an application is speci¬ 
fied using class diagrams and state machines 
(equivalent to other approaches that use class 
diagrams and activity diagrams). However, we 
argue that approaches based purely on UML- 
style models, even with action languages, lack 
the expressiveness necessary to capture appli¬ 
cation patterns and complex behaviour such 
as call-backs. Such approaches are often based 
on stereotypes and lack analysis tools such as 
type-checkers. Therefore, we propose a calcu¬ 
lus, called Widget, used to represent complete 
rapp applications. Widget has a precisely de¬ 
fined operational semantics and a type system 
that can be statically checked. Structure and 
behaviour diagrams are views of partial Wid¬ 
get programs and we define a translation from 
models to Widget. 

1.2 Problem and Contribution 

The complexity and diversity of rapp imple¬ 
mentation platforms can be addressed by suit¬ 
able MDD approaches. However current ap¬ 
proaches are lacking in terms of implementa¬ 
tion independence, behavioural completeness, 
and support for application analysis. A lack 
of behavioural completeness compromises the 
model driven aims of these technologies in 
terms of being technology independent since 
the code that is produced must be edited in 
order to run on each target platform. Where 
there are many different target platforms for 
a single application, this can be a significant 
task. 

This article addresses the following prob¬ 
lems in applying MDD techniques to rapp de¬ 
velopment. Firstly, MDD techniques often use 
a domain specific language (DSL) to repre¬ 
sent a family of related applications. There are 
candidate DSLs for rapp development, how¬ 
ever as described in section 6 there are limita¬ 
tions in terms of completeness or consistency 
with rapp implementation platforms. We per¬ 
form a domain analysis that leads to a list 


of key features that must be supported by 
any DSL. Secondly, there is no generally ac¬ 
cepted mechanism for expressing rapp mod¬ 
els. The Unified Modelling Language (UML) 
is the most widely used modelling notation in 
both academia and industry. Although UML 
supports features for general application de¬ 
velopment, and therefore can support rapps, 
it is usual to support DSLs in UML via stereo¬ 
types. A stereotype is a specialization of a 
standard UML element that is tagged for a 
specific purpose, for example tagging a class 
as a relational database table. There is no 
set of stereotypes (or profile) for expressing 
rapp models in UML and we use the domain 
analysis to derive a rapp profile. Finally, de¬ 
tailed execution in UML models can be ex¬ 
pressed using a general purpose action lan¬ 
guage that provides features similar to a stan¬ 
dard programming language. Since the UML 
action language is general purpose it does not 
constitute a DSL for rapp and therefore does 
not provide specific help for the verification 
of rapp models. We present a calculus called 
Widget that is used as the action language for 
the rapp profile. 

Widget is based on a functional language 
because it is simple and universal. Functional 
languages are increasingly used as an alterna¬ 
tive traditional languages for web applications 
[?,?,?] partly because of the need for inter¬ 
active applications to deal with continuations 
and partly because of the interest in state-less 
concurrent applications [?]. In addition the 
characteristic features of rapp applications are 
identified by adding them to a A-calculus in 
a simple way, for example using higher-order 
functions as event handlers, continuations and 
to structure hierarchically organized applica¬ 
tion objects. We use an approach based on 
monads to contain those parts of an appli¬ 
cation that deal with updating state (SQLite 
for example). As described in [?] this supports 
the desirable situation where applications can 
be built from composable units. 

The languages are exemplified in terms of 
a context aware application defined in [?] 




Fig. 1 . Model Driven Reactive Applications 

called Buddy. The DSML is used to express 
the structure and state-transition behaviour 
of Buddy which is then translated to Widget. 
A Widget interpreter has been developed in 
Java and used to implement the case study. 

The overall approach is shown in figure 1 
where a reactive application model consists 
of structure, behaviour and some constraints. 
A semantic mapping is used to translate the 
model to Widget where it can be extended 
with detailed behaviour. An implementation 
mapping is then viewed as a refinement of 
the semantics mapping in that it translates 
the Widget program for an appropriate im¬ 
plementation platform. The implementation 
mapping can be performed many different 
times for the same Widget program in order 
to target multiple technologies. An interpreter 
for the calculus has been written in Java and 
used to implement Buddy against an external 
widget library written in Swing; figures 2, 3 
and 4 are screen shots of the application. 

The rest of the article is organized as fol¬ 
lows: Section 2 describes a typical rapp case 
study called Buddy and performs domain- 
analysis in order to identify key features. Sec¬ 
tion 3 introduces a modelling language based 
on UML class diagrams and state machine 


that can be used to represent application 
structure and behaviour; a model is given for 
Buddy. Section 4 introduces the Widget cal¬ 
culus and section 5 shows how rapp models 
are translated to Widget. Finally, section 6 de¬ 
scribes related approaches and compares them 
to rapp models and Widget. 

2 Reactive Applications 

Reactive applications have several common 
features. The user interacts via a collection of 
screens and initiates computation by perform¬ 
ing actions that raise events and the applica¬ 
tion performs state transitions in response to 
receiving events. This section provides a sim¬ 
ple example of a rapp in section 2.1 and per¬ 
forms domain analysis in section 2.2 that iden¬ 
tifies the key common features. The screen- 
shots in this section are taken from the pro¬ 
totype Widget interpreter with a Java Swing 
external widget interface and where user in¬ 
teraction events have caused state transitions. 

2.1 Example Application: Buddy 

Figure 2 shows a mobile phone. The phone is 
always in contact with its network provider 
via a transmission cell located nearby. Each 
phone has a unique address that is used by 
























others to contact the user, in this case it is 

tonyOwidget.org. 



Fig. 3. Tony Knows Sally 


Each phone contains a database of contacts. 
New contacts can be added by clicking on the 
add button and entering the contact details. 
As shown in figure 3, Tony knows the address 
of Sally. A new contact is added by clicking 
on the add button; clicking on back returns 
to the previous screen. 

Multiple phones are always in contact with 
the service provider via the local cell. Users 
want to know about contacts in their database 
that are co-located. If Tony or Sally move 
within a predefined distance then Tony is in¬ 
formed as shown in figure 4. 

To achieve this the service provider is told 
of the location of each phone; when one phone 
moves into the vicinity of the other then both 
phones are told of the availability of the other 
in terms of the contact address. If the ad¬ 
dress is in the user’s database then the phone 
flashes the contact. 

This application has some key features. It 
is event driven where events arise either from 
the user (pressing a button) or as changes 
in the context (buddy is in range). The ap¬ 
plication interfaces are simple and organized 
hierarchically (for example the home screen 


contains a clock, a function button area and 
a numeric keypad). The application proceeds 
through a number of states, driven by the 
events (the home state, the add-contact state, 
the buddy-alert state). The application has 
transient data (the values typed in the name 
and address fields in the add-contact screen) 
and persistent data (the list of contacts). 


2.2 Domain Analysis 

A domain specific language is defined by per¬ 
forming a domain analysis [?] on a target fam¬ 
ily of applications in order to identify the com¬ 
mon characteristic features. The domain anal¬ 
ysis leads to the design of a technology that 
conveniently supports these features. Our do¬ 
main analysis included working with a media 
company to develop two iPhone applications: 
firstly to report Tour de France cycle race re¬ 
sults and secondly an on-line quiz. The do¬ 
main analysis for rapp identified the following 
key features: 

Screen Real Estate: Different platforms 
make varying amounts of screen available. For 
example a mobile platform is different to a 
tablet which is different to a desktop browser. 
The standard iPhone resolution is 480 by 320 
pixel and the IPA supports a 1024 by 768 reso¬ 
lution. This compares to the Android screens, 
which vary by hardware vendor but resolu¬ 
tions range to about 480 by 800 pixel. How¬ 
ever, in most cases the application logic is the 
same; how it is realized in terms of the screen 
real estate can differ. Abstracting away from 
the details of cross-platform differences is de¬ 
sirable when maintaining a single application 
across multiple targets. 

Layout Control: Layout control is an im¬ 
portant consideration. Android controls lay¬ 
out through the use of XML hies, support¬ 
ing different layout styles (linear, relative and 
absolute). This compares to iPhone, that can 
do programmatic layout and XML type inter¬ 
faces using Interface Builder. Like screen size, 
it is desirable to focus on application logic and 
























Fig. 4. Move in Range 


factor out the layout control details into ex¬ 
ternal libraries. 

GUI Element Containership: Most plat¬ 
forms use a form of GUI element container- 
ship. In iPhone development, the emphasis 
is on the application window with views and 
sub-views. These are then ‘stacked’ onto each 
other to create structured interfaces. Android 
uses a similar approach in terms of views and 
view-groups. Interface control on both plat¬ 
forms have similarities and differences. On the 
iPhone, views are normally controlled by the 
use of view controllers that contain event han¬ 
dlers. In comparison, Android development 
uses intents and activities. HTML structures 
interfaces in terms of documents, tables, div’s 
etc. This feature leads us to conclude that a 
large number of rapp GUIs can be expressed 
in terms of a tree of widgets that manage 
data and behaviour and whose detailed lay¬ 
out and rendering properties can be factored 
into platform specific libraries. 

Event Driven Applications: Most mobile 
application implementation languages regis¬ 
ter event handlers dynamically. Web applica¬ 
tions process events by dynamically testing 
identifiers embedded in URLs. This method 
means there is a lack of checking at compile 
time to prevent an application crashing. Con¬ 
textual events such as platform orientation, 
GPS, and battery levels must be handled by 


a mobile application in suitable ways. This 
places a desirable feature requirement on de¬ 
velopment whereby the presence or otherwise 
of event handlers can be detected at compile¬ 
time. 

Hardware Features: Modern day mobile 
devices come equipped with many different 
features. These features include microphones, 
accelerometers, GPS, camera, and close range 
sensors. These features tend to be fairly stan¬ 
dard in their behaviour if they are supported 
by the platform. Although many platforms 
have comparable hardware features, they dif¬ 
fer in the details of how to control and re¬ 
spond to them, rapp development should al¬ 
low the details of hardware to be factored out 
into platform specific libraries whilst support¬ 
ing the events and controls associated with 
them. 

Object-Orientation: Mobile and web- 
based applications are typically 00. iPhone 
uses Objective-C and Android uses Java. 
Javascript which is used by many web ap¬ 
plications has an object-oriented collection 
of data types for building applications. 
Applications are built by constructing new 
and extending existing class/object types. 

Transitional Behaviour: rapps execute in 
response to events that originate either from 
the user or as context events from the plat¬ 
form. The application performs a state tran- 
























sition in response to an event causing a change 
to the application’s state (or to a system that 
is connected to the application) and possibly 
a new interface screen. 

Data Persistence: rapps usually need to 
persist data to physical storage between appli¬ 
cation invocation. Modern smartphone plat¬ 
forms currently have implementations of a 
SQLite, a lightweight serverless single hie 
database engine. 

Contextual Events: Within a mobile ap¬ 
plication, not all events are directly invoked 
by the user. Mobile platforms have to deal 
with event invocation from a range of differ¬ 
ent sources based on its current contextual en¬ 
vironment. For example, when the battery is 
low on a phone normally the phone will dis¬ 
play a message to the user to recharge the 
battery. 

Static Typing: Type systems are used in 
programming languages as a method of con¬ 
trolling legal and illegal program behaviour. 
Static typing requires all type checking to be 
carried out during run time, as opposed to 
dynamic typing that requires checking at run¬ 
time. Since rapps rely heavily on events and 
event handlers, it is desirable that a program 
can be statically checked in order to match 
handler definitions against all possible events 
that can be raised. 

3 Reactive Models 

Reactive models must support the key fea¬ 
tures that were identified in 2.2. We use a DSL 
based on stereotyped UML class diagrams to 
represent the structure of rapp models and 
UML state machine models to represent their 
behaviour. A stereotype is a tag of the form 
«name» that is added to a standard UML 
element in order to designate it for a specific 
purpose. The tags are available to tools that 
process UML models so that they can take 
special action when generating code for ex¬ 
ample. 

The stereotypes are used by the semantic 
mapping to encode the structure into Widget 


and the state machine is used to define Wid¬ 
get event handlers that make transitions be¬ 
tween screens. Section 3.1 describes the DSL 
used for modelling, section 3.2 describes the 
structure of the Buddy phone application and 
section 3.3 describes its behaviour. 

3.1 Modelling Features 

A rapp model is represented using a DSL 
for structure and a UML state machine for 
behaviour. The structure of a rapp is con¬ 
structed using widgets that generate and han¬ 
dle events. External widgets, represented as 
classes with stereotype <<external», are 
provided by the implementation platform. All 
widgets inherit from the abstract external 
Widget class. User-defined widgets typically 
extend external widgets and are identified by 
the stereotype <<widget». 

Widgets define properties that are set when 
the widget is instantiated. These are defined 
on a model using standard UML-style at¬ 
tributes. Widgets may also define queries, 
events, commands and handlers. A query is 
an operation that can access the current state, 
but cannot make any change to it; it is de¬ 
fined as a standard UML operation on a class. 
An event is a named, structured value that 
can be raised by a widget. An external wid¬ 
get generates events as a result of a change 
to the world state; user-defined widgets gen¬ 
erate events when they fail to handle an event 
generated by a widget they contain. In addi¬ 
tion user-defined widgets can explicitly gener¬ 
ate events. Events are defined as an operation 
with stereotype <<event». A command is an 
operation that can change the program state; 
it is specified using the «command>> stereo¬ 
type; associations and properties can also be 
tagged as commands when their values de¬ 
pend on the program state. A handler is a 
widget operation, tagged «handler>>, used 
to handle events when they are raised. 

Widget references are defined using asso¬ 
ciations. Widget containment hierarchies are 
modelled using UML black-diamond. Widget 



containment is used to construct hierarchi¬ 
cal GUIs and also to define how events are 
handled. Events raised by a widget must be 
matched with a handler with the correspond¬ 
ing signature (name and arguments). If the 
widget raising the event defines such a han¬ 
dler then the event is supplied to the handler 
that must produce a replacement for the wid¬ 
get in the containment hierarchy. Otherwise, 
the widget does not define a handler so the 
search continues with the parent. If the par¬ 
ent handles the event then the parent is re¬ 
placed in the containment hierarchy. This pro¬ 
cess continues until a handler is found; static 
type checking guarantees that a handler will 
be found for all events that can be raised. 

The structure of a rapp is a collection of 
state models each of which must have a root 
container widget. The root is the GUI element 
that contains and references all other widgets 
in that system state. A general purpose root 
container is the external Window widget that 
contains GUI elements displayed on a phone 
screen or a browser window. Window can be 
specialized to produce application-specific ex¬ 
ternal widgets. 

3.2 Phone Structure 

The structure of the Buddy application is 
defined using four state models that corre¬ 
spond to different screens. This section de¬ 
scribes three of these state models, the fourth 
is a simple variation and so is omitted. 

Figure 5 shows the state model for the main 
screen. All of the state models define root con¬ 
tainer widgets that extend Phone which itself 
extends Window. The Phone widget is exter¬ 
nal and must display a title, a display wid¬ 
get and some buttons in an appropriate way 
that can differ between target implementation 
platforms. In addition to the events generated 
by the contained display and button widgets, 
Phone will generate a move event since it in¬ 
herits from Window. 

The Main root container specializes the dis¬ 
play and buttons associations so that the 


main screen of the application presents a clock 
and offers buttons for adding and deleting 
contacts. The Clock widget is external and 
raises no events. Each button widget spe¬ 
cializes external Button that raises a push 
event (including a unique numerical id) when 
pressed. Both AddButton and DelButton have 
handlers for the push event that translate it 
into an add and del event respectively. The 
Main widget defines handlers for add and del 
that make a transition to new application 
states as described below. 

The Main widget also contains a Notifier 
that is an external widget used to manage 
connections to the service provider. Two com¬ 
mands, connect and register, are used to 
initiate the connection with the provider af¬ 
ter which notify events will be generated 
when any phone that is connected to the same 
provider comes into range. Main handles move 
events that are passed on to the notifier when¬ 
ever a phone moves from one cell to another. 

Each state in the model has a reference to 
a database widget DB. The database widget 
manages a collection of records and provides 
commands for deleting and modifying records 
in the database. Note that the relationship be¬ 
tween Main and DB is not containment because 
the database does not generate any events. 

The system state used to add new contacts 
to the database is shown in figure 6. The 
root container is Add, the display is an exter¬ 
nal widget AddScreen that manages browsing 
and adding new contact records. AddScreen 
provides two commands that are used to yield 
name and address strings that have been en¬ 
tered by the user via platform-specific text 
editing implemented by the AddScreen wid¬ 
get. Buttons provided in the Add state pro¬ 
duce add and back events. The add event 
updates the database before returning to the 
Main widget and the back event just returns 
to the Main widget as described in section 3.3. 

Invariant constraints are expressed us¬ 
ing OCL. The Add widget must share the 
database, title and notifier with the Main wid¬ 
get: 




Fig. 5. Main Screen 



Figure 7 shows the widget for the notifica¬ 
tion screen that occurs when a contact is de¬ 
tected in range. The display is simply a label 
informing the phone user that the contact is 
nearby and the button dismisses the notifica¬ 
tion and returns to the Main screen. The title 
of the screens are the same: 

context Notify inv: 
m.title = title 


Fig. 7. Notify Screen 

context Add inv: 

m. contacts_db = db and 
m.notifier = notifier and 
m.title = title 

The widget that implements contact deletion 
is similar to Add and is therefore not defined 
in this article. 


3.3 Phone Behaviour 

The behaviour model for the phone applica¬ 
tion is shown in figure 8. Each state corre¬ 
sponds to a root container widget. Transitions 
correspond to the events that are handled by 
a root container. The figure shows that the 
application starts in the Main state. Pressing 
the add or del buttons cause a correspond¬ 
ing state transition. Notification events are ig¬ 
nored unless they occur in the Main state; if 































































Fig. 6. Add New Contacts 


the contact is known then they are displayed 
via the Notify state, otherwise the event is 
ignored. 


4 The Widget Calculus 


The Widget Calculus is a simple functional 
language that has been designed to support 
rapp programs. Widget is both stand-alone 
and can be used as the target of a rapp PIM. 

In addition to being a standard functional lan- z 
guage, Widget provides three key rapp ele¬ 
ments: widgets that encode sources of reactive 
behaviour including both externally defined 
widgets and user-defined widgets; commands 
that make changes to the current world-state; 
events that arise from state-changes includ¬ 
ing both externally generated events and user- 
defined events. The core syntax of Widget- 
expressions is defined in figure 9. The rest of 
this section describes features of the syntax 
and concludes with an informal description of 
its operational semantics. 


: = 


expressions 

i 

X 


variables 

2 

k 


constants 

3 

[e,...] 


lists 

4 

{x=e;...} 


records 

5 

e. x 


field refs 

6 

fun(x: t, . . . ) : t e 


functions 

7 

e(e, . . .) 


applications 

8 

if e then e else e 


conditionals 

9 

fix (e) 


fixed points 

10 

raise x(e,. . .) 


events 

11 

do {x:t<-e;...; return e} 


blocks 

12 

widget x:t (e) {x:t<-e;... 

.} 

widgets 

13 

top 


universal 

14 

Fun[x,. . .] e 


type abstraction 

15 

e[t, . . . ] 


instantiate type 

16 

:= x(t,...) 


events 

17 

: = 


values 

18 

X 


variables 

19 

k 


constants 

20 

[v,...] 


lists 

21 

{x=v;...} 


records 

22 

fun(x:t, . . . ) :t e 


functions 

23 

raise x(v,. . .) 


exceptions 

24 

do {x:t<-e;...; return e} 


blocks 

25 

widget x:t (e) {x:t<-e;... 

.} 

widgets 

26 

top 


universal value 

27 

rig. 9. Widget Expressions, Commands, Values 













notity(address : String) 



notity(address: String) [ 
has_contact(address,contacts_db. records)] 


backQ 


move(x: Integer, y: Integer) 



Notify ^ 





notitV(address : String) 


move(x: Integer, y: Integer) 


Fig. 8. State Transitions 


4.1 Basic Features 

Widget consists of standard functional lan¬ 
guage expressions defined in figure 9: vari¬ 
ables (2), strings (3), numbers (3), booleans 
(3), lists (4), records (5), field references (6). 
Functions (7) include the types of the argu¬ 
ments and the return type. Applications (8) 
and conditionals (9) are standard. A recur¬ 
sive definition is created using a fixed-point 
expression (10) in the usual way such that 
f (f ix(f ) )=f ix(f ) (syntactic sugar is used to 
define mutually recursive local definitions as 
letrec using fix in the usual way). Mutually 
recursive top-level definitions are introduced 
by keywords fun, val, type. 

4.2 Polymorphism 

Widget is a statically-typed language and 
supports operators that construct external 
widgets (see below). An example of such an 
operator is db that creates a database wid¬ 
get that maps keys to values, and that im¬ 
plements commands to update and access the 
database. The behaviour of a database is in¬ 
dependent of the actual types of the keys and 


values, therefore the constructor db is poly¬ 
morphic. In order for Widget to statically 
check the use of databases, the key and val¬ 
ues types must be supplied to the constructor: 
db[int,str] or db[str,int] etc. 

Programs that work uniformly over all 
types (such as many list processing func¬ 
tions) can be declared with respect to one 
or more type parameters (15). When an ex¬ 
pression that is parametric in one or more 
types is used, the actual type is supplied as 
an argument (16). A standard example is 
the identity function declared as: id=Fun[t] 
fun(x:t) :t x and then used in two different 
ways: id [int] (10) and id [bool] (true). A 
special constant is used for the empty list: 
[] [t] in order to declare the type of the 
elements; therefore the empty list of inte¬ 
gers [] [int] is different to the empty list of 
strings [] [str]. 

4.3 Commands 

Commands are values that can be used to 
query the program state or to change program 
state or both. The program state includes the 






current collection of widgets, therefore there 
are commands that create new widgets (we 
assume inaccessible widgets are garbage col¬ 
lected). The details of the program state de¬ 
pends on the set of imported external widgets 
that are used, for example an external widget 
that implements a database will have state 
that is modified by adding and removing ele¬ 
ments. 

The underlying platform may also generate 
events that must be handled by user code. 
For example an external widget that man¬ 
ages the battery in a mobile phone may gener¬ 
ate events when the amount of charge reduces 
below a preset level. User defined commands 
may choose to handle an event or to promote 
the event to a surrounding handler. Therefore 
commands can also generate events. 

Widget commands are values that can be 
passed as values and returned as results. 
Therefore a command expression evaluates to 
produce a command. A command expression 
has the type <t> and we say that the de¬ 
noted command is performed to yield a value 
of type t. Typically command expressions are 
used as follows: to express a user-defined wid¬ 
get; to initialize the fields of a user-defined 
widget; to define the body of a handler in 
a user-defined widget. The latter is interest¬ 
ing because user-defined widgets have fields 
that can hold any type of value, therefore 
a field that contains a function whose body 
is a command-expression is equivalent to a 
method in an object-oriented programming 
language. 

Widget has some built-in commands and 
the do-expression (12) that builds compos¬ 
ite commands. Locations containing values 
of type t have a type !t. The following 
builtin operators deal with locations: loc 
has type Forall(t) (t) —><! t>, get has type 
Forall(t) (!t) -><t> and set has the type 
Forall(t) (!t,t)-><t>. The following func¬ 
tion maps locations to commands that add 1 
to the contents of the location and yields the 
new value: 


fun addl (1: ! int) : <int> = do { 
x:int <- get [int] (1) ; 
y:int <- set [int] (l,x+l) 
return y 

} 

Commands are first-class values that can be 
passed as arguments and returned as results. 
Commands can also be nested as shown in the 
following example: 

fun add2(l: ! int) : <int> = do { 
void:int <- addl(l); 
z:int <- addl(1); 
return z 

} 

Events are generated by a raise command 
(11) that, when performed, yields a distin¬ 
guished value *, and is processed as described 
below. 

4.4 Widgets 

A widget definition (13) is a command that 
yields a new widget. Each widget has the fol¬ 
lowing form: 

widget self:t (parent) { 
xl:tl <- el; 

xm:tm <- em 

} 

where self is the name that can be used in 
the body of the widget to refer to itself and 
may be omitted if not used. All widgets in¬ 
herit from a parent widget supplied as a com¬ 
mand. The special command top (14) is used 
to create a distinguished widget that has no 
parent and acts like Object in object-oriented 
programming languages. 

The idea is that user-defined widgets ulti¬ 
mately inherit from external widgets. The ex¬ 
ternal widget will generate an event that the 
child can handle via its components. If the 
user-defined widget does not define any com¬ 
ponents then it is equivalent to the parent: 

widget (p) {} = p 

Each definition x:t <- e in the body of the 
widget defines a command e that yields a 
component. The component is named x and 



can be referenced within other definitions and 
the parent. We use the convention that defini¬ 
tions whose value is a function can define the 
function in-line and that x:t = e is equiva¬ 
lent to x:t <- do { return e }. 

A widget may define any type of com¬ 
ponent, but typically contains widgets and 
functions. The contained widgets raise events 
some of which may be handled by the con¬ 
tainer’s functions. The scope of variables in 
widget body definitions are scoped so that 
names used earlier in the list are scoped over 
values later in the list except for function 
definitions that are only available as event 
handlers. Therefore, value and function def¬ 
initions in widgets can be treated separately 
by re-ordering values before functions in the 
body. Furthermore, it is possible to simplify 
any definition using the following equivalence: 

widget (e) { x <- e; d } = 
widget (widget (e) { x <- e }) { d } 

Each handler function must return a com¬ 
mand that yields a widget. For example, if 
a window contains a single button that does 
nothing when it is pressed then we construct 
a widget with a parent using the external con¬ 
structors window and button: 

widget 

self:MyWindow 

(window(’My Window’.button(’PUSHME’))) { 

push(id: int) : <MyWindow> = do { return self } 

> 

In the widget above, the parent is a window 
with a title 5 My Window’. The contents of 
the window is the button button (’ PUSHME ’). 
When a button is selected, it generates events 
of the type push (int). Since the widget de¬ 
fines a handler whose signature matches the 
event then the handler defines a replacement 
for the entire window when the button is 
pressed. The handler returns a command that 
yields self, causing the window to be re¬ 
placed with itself, i.e. nothing happens when 
the button is pressed. 

Equivalently, the handler can be processed 
by the component widget. In the following, 


the button b handles the push event; the but¬ 
ton is replaced with itself inside the window: 

widget(window(title,b)) { 
title:str = ’My Window’; 
b:MyButton <- 

widget self:MyButton (button(’PUSHME’)) { 
push(id:int):<MyButton> = do { 
return self 

} 

> 

} 

The following is a window that oscillates be¬ 
tween two buttons when they are pressed: 

widget(window(’MyWindow’,bl)) { 
bl:MyButton <- 

widget(button(’FORWARD’)) { 
push(i: int):<MyButton> = do { 
return b2 

} 

}; 

b2:MyButton <- 

widget (button(’BACK’ ) ) { 

push(i:int):<MyButton> = do { 
return bl 

} 

> 

} 


4.5 Two Examples 

A Widget program cycles through the follow¬ 
ing phases: 

reducing an expression to produce a com¬ 
mand. This involves applying operators 
to operands and the construction of basic 
data structures. Reduction is side-effect 
free. 

performing a command with respect to the 
state of a root widget. The command can 
change the state of the widget tree and 
its context. For example, a command allo¬ 
cates unique identifiers to widgets or calls 
a system library to update or access a lo¬ 
cal database. 

displaying a widget tree in a technology- 
specific way and waiting for an event. The 
event may originate from a user interac¬ 
tion with the system or may originate from 
the system context. In all cases an event 



can be associated with a unique widget in 
the tree. 

processing an event by delivering it to a 
uniquely identified widget (the receiver). 
The event names a handler in the receiver 
whose body is produces a new expression 
ready for a fresh reduction step. The re¬ 
duction produces a command that is per¬ 
formed to produce a replacement widget 
for the receiver. 

This section contains two simple examples 
that show how these phases operate in terms 
of the calculus. 

Example 1: A screen widget contains a single 
button that displays a label PUSHME. Pushing 
the button is an identity step on the system. 
The starting expression is: 

letrec 
main = 

widget self (screen(50,50,50,50,push)) { 
move(x,y) = do { return self } 

>; 

push = 

widget self (button(’PUSHME’)) { 
push(i) = do { return self } 

> 

in main 

After reduction we get the following com¬ 
mand: 

widget self (screen(50,50,50,50, 
widget self (button(’PUSHME’)) { 
push(i) = do { return self } 

» { 

move(x,y) = do { return self } 

> 

The command is performed by allocating 
unique identifiers to each widget in the tree. 
The built-in widgets screen and button are 
allocated identifiers 2 and 0 respectively. The 
user defined widget identifiers are shown in 
parentheses after the keyword widget: 

widget(3) self (screen(2,50,50,50,50, 
widget(l) self (button(0,’PUSHME’)) { 
push(i) = do { return self } 

» { 

move(x,y) = do { return self } 

> 

The displaying phase then displays the tree 
as a screen containing a button. An event 
is receieved when the user presses the but¬ 
ton with identifier 0. This is denoted as 


<w>i<-push(i) where the argument to push 
is the source identifier (in case handlers are 
shared between different widgets). 

Processing an event traverses the widget w 
until the identifier i is found. When the wid¬ 
get with identifier i is found we will retain the 
context so that it can be replaced: 

<widget(3) self (screen(2,50,50,50,50, 
widget(l) self (button(0,’PUSHME’)) { 
push(i) = do { return self } 

> { 

move(x,y) = do { return self } 

}>0<-push(0) 

Widgets 3 and 2 are incorrect so the search 
moves down the tree: 

widget(3) self (screen(2,50,50,50,50, 

<widget(l) self (button(0,’PUSHME’)) { 
push(i) = do { return self } 

}>0<-push(0))) { 

move(x,y) = do { return self } 

> 

The widget with identifier 1 contains the wid¬ 
get with identifier 0. A button widget is ex¬ 
ternal and does not define any handlers, there¬ 
fore its inner-most container that defines a 
handler with the appropriate name will han¬ 
dle the event. The body of the handler is an 
expression that is reduced to produce a com¬ 
mand (denoted using < and >): 

widget(3) self (screen(2,50,50,50,50, 

<do { 

return widget(l) self (button(0,’PUSHME’)) { 
push(i) = do { return self } 

> 

») { 

move(x,y) = do { return self } 

> 

Performing the command returns a widget 
that is used as a replacement for the receiver. 
Since the command returns the receiver (via 
self) this is an identity step: 

widget(3) self (screen(2,50,50,50,50, 
widget(1) self (button(0,’PUSHME’)) { 
push(i) = do { return self } 

}) { 

move(x,y) = do { return self } 

> 

The tree is now ready to receive further events 
and the process loops indefinitely. 

Example 2: Our second example shows how 
multiple events are handled. Of course since 



events originate from user interaciton, they 
are serialized, however they may target dif¬ 
ferent GUI widgets. The following example 
shows how a button toggles between two 
states. The following mutually recursive defi¬ 
nitions create a screen: 

letrec 
main = 

widget self (screen(50,50,50,50,push)) { 
move(x,y) = do { return self } 

>; 

push = 

widget (button(’PUSHME’)) { 
push(i) = do { return pushed } 

>; 

pushed = 

widget (button(’PUSHED’)) { 
push(i) = do { return push } 

> 

in screen 

They evauate to produce a command: 

widget self (screen(50,50,50,50,push)) { 
move(x,y) = do { return self } 

> 


move(x,y) = do { return self } 

> 

The result is a new screen where the button 
has changed state: 

widget(5) self (screen(4,50,50,50,50, 
widget(2) (button(l,’PUSHED’)) { 
push(i) = do { return push } 

})) { 

move(x,y) = do { return self } 

> 

The event l<-push(l) causes an equivalent 
sequence of changes to occur, resulting in the 
original system state: 

widget(5) self (screen(4,50,50,50,50, 
widget(3) (button(0,’PUSHME’)) { 
push(i) = do { 

return widget(2) (button(l,’PUSHED’)) { 
push(i) = do { return push } 

> 

> 

})) { 

move(x,y) = do { return self } 

> 


The command is performed to allocate unique 
identifiers: 

widget(5) self (screen(4,50,50,50,50, 
widget(3) (button(0,’PUSHME’)) { 
push(i) = do { 

return widget(2) (button(l, ’PUSHED’)) { 
push(i) = do { return push } 

> 

> 

») { 

move(x,y) = do { return self } 

> 

The event 0<-push(0) is received and targets 
the appropriate widget: 

widget(5) self (screen(4,50,50,50,50, 

<widget(3) (button(0,’PUSHME’)) { 
push(i) = do { 

return widget(2) (button( 1,’PUSHED’)) { 
push(i) = do { return push } 

} 

> 

}.push(0)>)) { 

move(x,y) = do { return self } 

> 

It is handled and produces a command that, 
when performed, produces a replacement wid¬ 
get for 3: 

widget(5) self (screen(4,50,50,50,50, 

<do { 

return widget (2) (button(1,’PUSHED’)) { 
push(i) = do { return push } 

»)) { 
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4.6 Types 

Reactive applications execute in terms of 
function application, message passing and by 
handling events. Some implementation tech¬ 
nologies such as Javascript, are dynamically 
typed, and others, such as Java for Android, 
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are statically typed. In virtually all cases, 
events are handled by registering event han¬ 
dlers with the underlying framework so that 
the handler is called when the event occurs. 
Handler registration occurs at run-time; in 
such languages it is not possible to statically 
analyze an application for the existence of all 
required handlers. 

Widget is a strongly typed, statically 
checked language. In addition to statically 
checking that the types of operator arguments 
and field references are correct, Widget can 
check that all possible events raised by an 
application have an appropriate handler def¬ 
inition. For context aware applications this 
means that a tool can check that all situations 
are handled, for example low battery power, 
change of platform orientation, etc. Whilst 
this does not guarantee the the application is 
correct, it reduces the possibility that the de¬ 
veloper has inadvertently omitted a handler 
definition that could lead to sub-optimal or 
inappropriate application behaviour. 

The types are defined in figure 10. Con¬ 
stants are strings, integers or booleans (1-3), 
a list must contain elements of a single type 
(4), the types of each field in a record may be 
different (5), a command that yields a value 
of type t is of type <t> (6), a value of a union 
type (7) is a value of either component type, a 
widget expression is a command that yields a 
value of a widget type (8) and each component 
field in the widget expression must be a com¬ 
mand that yields a value of the corresponding 
field type, the expression top is a command 
that yields a value of type Top (9), a function 
has a function type (10), a universal type (17) 
can be applied to type arguments to yield a 
type (11), a type may be recursive (12), types 
may be bound to type variables (13), types 
may be packaged up into type records (14) 
and referenced (15), finally, an event raising 
expression is a command that yields the value 
of type * (16). 

Figure 11 defines a relation between type 
assignments T, expressions e and types t such 
that r b e : t holds when e is assigned type t 


when free variables in e are assigned types by 
r. The relation is standard except in terms of 
event handling where raisesX is written f X 
for brevity. T-IF combines the types of the 
consequent and alternative arms a © /3 where 
((f) t x) © ((If) t X') = {t + t') t X U X', 
otherwise © is the same as +. T-EXC defines a 
raise command to yield the unit value and to 
raise an event of the appropriate type. T-DO 
combines all events raised by the definitions. 

The refactoring of widget expressions in 
section 4.4, where single value definitions are 
extracted the parent, allows us to define wid¬ 
get type assignment as two separate rules T- 
WID1 and T-WID2. The shorthand W(X) 
is used for Widget (t) raises X d where 
only the events X raised by the widget type 
are of interest. T-WID1 defines type assign¬ 
ment where the body of a widget consists of 
handler definitions; the events handled by the 
child are erased from those raised by the par¬ 
ent. In T-WID2 the events raised by the con¬ 
tained widget are added to those raised by the 
parent. 



Fig. 12. Execution Cycle 


4.7 Operational Semantics 

In order to run on a platform, a Widget pro¬ 
gram must have a specific type: (W(0)) t 0> 
i.e. a command that yields a widget whose 


events have all been erased. Program execu¬ 
tion cycles through four stages: evaluation; 
commands; display; event handling. Firstly 
the program is evaluated, or reduced, to pro¬ 
duce a value, or normal form. Given the type 
restrictions, the value is a command that 
yields a widget as a result of the second stage 
of execution. The second stage can perform 
side-effects. 

A widget is a tree t whose leaves are ex¬ 
ternal widgets (or top); the tree is projected 
onto a tree i! of external widgets that is dis¬ 
played on an implementation platform. The 
third stage of execution displays t!. At this 
point the application waits to receive an event 
e, either from the underlying platform (a con¬ 
text event) or from user interaction. Stage 
four involves handling e by mapping from the 
receiving external widget in t! to the corre¬ 
sponding widget w in t. By traversing from 
w to the root of 1 a most specific handler h 
is found. The body of h is an expression e of 
type (yV'{X)) f X' that yields a replacement 
for w. Since e is of the appropriate type, eval¬ 
uation can re-start from stage one. 

The operational semantics of Widget pro¬ 
grams is shown as a state-machine in figure 12. 
The root container widget is called root and 
on the first iteration the starting state shown 
at the top of the diagram is e=root=w and 
root: <W> where W is a sub-type of Window. 
Reduction produces a command v:<W>. The 
command is performed with respect to the 
program state s to yield a value v ’ and a new 
state s ’. The value v ’ is the replacement for 
the current target of the event: w in root (in 
the first case this replaces the root with it¬ 
self). The root containment tree is projected 
onto a tree of builtin widgets using external 
which is then displayed on a screen. The sys¬ 
tem then waits for an event z which is sent to 
a widget w that is contained in root. At this 
point the target widget e is reset to the body 
of the handler for z in w. The cycle continues, 
each time, the target of an event is replaced by 
the value yielded by the body of the handler 
for the event. 


5 Mapping and Behaviour 

Section 3 has described how rapp models can 
represent a mobile phone application. Section 
4 has described a technology-independent lan¬ 
guage for representing reactive applications. 
The rapp modelling language could be trans¬ 
lated directly onto an implementation tech¬ 
nology. In practice, this is how things would 
be done; however, such a strategy leads to 
a semantic definition for the application in 
terms of an implementation platform. This 
strategy has two significant disadvantages: 
firstly implementation technologies tend to be 
complex; secondly if the application is to be 
realized across multiple platforms then it is 
much more attractive to use a technology- 
independent semantic domain. 

Our hypothesis is that Widget provides a 
suitable precise, lightweight and executable 
platform for rapps. This section describes a 
translation from rapp models to Widget pro¬ 
grams in terms of the Buddy case study. 

5.1 General Mapping 

The rapp modelling language consists of 
stereotyped class diagrams, state machines 
and invariant constraints. Event handlers are 
indicated on a class diagram using the 
<<handler» stereotype on a class operation, 
however the body of the operation may be 
omitted. As described in figure 1 models are 
translated to Widget programs; the resulting 
program is a skeleton if operation bodies are 
omitted from the source models. This section 
specifies the translation and shows a simple 
example with respect to the Main widget and 
associated state machine defined in section 3. 

In a rapp model, each widget class W is 
associated with a function F, M(W,F) where 
M is defined as follows: 

MO If W is tagged <<external» then F is 
a predefined function that constructs wid¬ 
gets of the appropriate type. 



Ml If W is tagged <<widget» then F is a 

function definition with the same name. F 

has parameters specified by: 

Al attributes of W or of any inherited or 
contained widget classes (except those 
for A3). 

A2 non-contained referenced widgets. 

A3 shared contained widgets (as specified 
by invariants). 

A4 the target of outgoing transitions 
from W and their associated argu¬ 
ments. 

and a body B that is a widget definition 

specified by: 

BO self is used for self-reference (the de¬ 
fault). 

B1 The parent of B is a widget con¬ 
structed by applying a function F’ to 
initialization arguments. If W’ is the 
super-class of W then M(W’,F’) must 
hold. The initialization arguments are 
supplied as required by A1-A4 in the 
context of F’ observing any sharing 
constraints. 

B2 There is a definition in B correspond¬ 
ing to each contained reference from 
W. If the reference is shared due to 
some constraint then it will have been 
passed as an argument. Otherwise it is 
constructed using the appropriate op¬ 
erator. 

B3 There is a function definition for each 
handler. The body of the handler must 
be a command. The state machine de¬ 
clares the target state for the handler. 
If this is a self-transition then the tar¬ 
get is self. Otherwise the transition 
is made by invoking the appropriate 
function for the target state passing 
any required arguments and observing 
any guards. 

B4 References to commands must be per¬ 
formed as command bindings. 

Consider the state Main. Applying M pro¬ 
duces the function shown in figure 13 (omit¬ 
ting type information) where the annotations 


on the right refer to the mapping conditions 
listed above. Where the rules refer to vari¬ 
ables, they are listed in parentheses. The fol¬ 
lowing section uses M to specify function def¬ 
initions for Buddy. 


The structure models in section 3.2 are trans¬ 
lated into Widget type definitions that define 
widget signatures as shown in figure 14. The 
type signatures encode information about the 
containment structure of the widgets, inher¬ 
itance from external widgets and the state 
transition from section 3.3 where each handler 
must return a command that yields a widget 
of the appropriate type. For example, when 
the back event in Add is handled, this will 
produce a widget of type Main because of the 
state machine in figure 8. The notify han¬ 
dler in Main yields a widget of type Notify 
or Main because there is a choice, modelled in 
figure 8 as two transitions with mutually ex¬ 
clusive guards that use has_contact to check 
whether an address exists in a sequence of 
records: 

rec fun has_contact (addr: str, contacts : [Record] ): bool 
if contacts = [] [Record] 
then false 
else 

let contact:Record = head[Record](contacts) 
in if contact.val = addr 
then true 

else has_contact(addr,tail[Record](contacts)) 

Each user defined root container is translated 
into a Widget function that returns a com¬ 
mand yielding a widget of the appropriate 
type. Figure 5 is translated into the defini¬ 
tion in figure 15. The main function returns a 
command (lines 1-21) that initiates some lo¬ 
cal variables (contacts_db,bl,b2,p) and then 
yields a widget of type Main. The operators 
clock, db and button (lines 2,3,4,6) are built- 
in commands and yield external widgets of the 
appropriate types. The main widget (lines 6- 
19) inherits from the built-in phone widget 
created using phone (line 6). The notifier (line 
7) must perform a command that initializes 


5.2 Mapping Buddy 



fun main(title,db,port,x,y) = 

Ml, Al(title,port,x,y), A2(db) 

widget (phone (title, clock(x,y) , [add() ,del ()] ) { 
n <- notifier(port); 
addO = add_screen(self ,db ,n) ; 

B3, A4(self), A2(db), A3(n) 

del() = del_screen(self,db,n); 

B3, A4(self), A2(db), A3(n) 
notify(address) = do { 
contacts <- db.records 
return 

if has_contact(addr,contacts) 
then notify() 
else self 

}; 

move(x,y) = do { 
void <- n.move(x,y) 
return self 

} 

> 


MO, BO, B1 
B2 


B3 

B4(records) 

B3 


B3 

B4 

B3(self) 


Fig. 13. Result of Applying M to Main 


type DoAdd = Widget (Button) raises add() { push: (int)-><*> raises add() } 
type DoBack = Widget (Button) raises back() { push: (int)-x*> raises back() } 
type DoDel = Widget (Button) raises del() { push: (int)-x*> raises del() } 
type Record = { key:str; val: str } 
type Main = Widget (Phone [Clock,DoAdd+DoDel] ) { 
notifier:Notifier; 
add:()-><Add>; 
del:()-><Del>; 

notify: (str)-XNotif y+Main> ; 
move: (int, int) -><Main> 

} 

type Add = Widget (Phone [AddScreen,DoAdd+DoBack] ) { 
notifier:Notifier; 
add:()-><Main>; 
back:()-><Main>; 
move: (int,int)-XAdd>; 
notify: (str)-XAdd> 

} 

type Notify = Widget (Phone [Label,DoBack] ) { 
notifier:Notifier; 
back: ()-XMain>; 
move: (int, int) -XNotify>; 
notify: (str)-XNotify> 


Fig. 14. Type Definitions 



fun mainO : <Main> = do { 

contacts_db: DB [str ,str] <- db [str ,str] ( ’tony_phone . dat ’ ) ; 
bl:<DoAdd> = widget (button( ’ add’) ) { push(i : int) : <*> = raise add() }; 
b2:<DoDel> = widget (button( ’ del ’ ) ) { push(i : int) : <*> = raise del() }; 
p:Main <- 

widget self:Main (phone[Clock,DoAdd+DoDel](’Tonys Phoneclock(50,50), [bl,b2])) { 
notifier:Notifier <- create_notifier; 
add():<Add> = add_screen(self,contacts_db,notifier); 
del():<Del> = del_screen(self,contacts_db,notifier); 
notify(addr:str):<Notify + Main> = do { 
contacts:[Record] <- contacts_db.records; 
notify:Notify <- notify_screen(self,addr,notifier) 
return if has_contact (addr, contacts) then notify else self 

>; 

move(x: int,y: int) : <Main> = do { 
void:bool <- notifier.move(x,y) 
return self 

} 

} 

return p 

> 


Fig. 15. The Main Widget 


1 fun notify_screen(m:Main,addr : str,n:Notifier):<Notify> = do { 

2 b:DoBack = widget (button(’back’) ) { push(i : int) : <*> = raise backO }; 

3 p:Notify <- 

4 widget self:Notify (phone [Label ,DoBack] (’Tonys Phone ’, label (’ CONTACT: ’ + addr),[b])) { 

5 notifier : Notifier = n; 

6 notify (addr : str) : <Notify> = do { return self }; 

7 backO : <Main> = do { return m }; 

8 move(x:int,y:int):<Notify> = do { 

9 return self 

10 } 

11 } 

12 return p 

13 > 
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Fig. 16. The Notify Widget 



1 fun add_screen(m :Main,db :DB [str ,str] ,n:Notif ier) : <Add> = do { 

2 records:[Record] <- db.records; 

3 s:<AddScreen> = addscreen(records); 

4 bl:<DoAdd> = widget (button!’add’)) { pushCi : int) : <*> = raise add() }; 

5 b2:<DoBack> = widget (button!’back’)) { push(i : int) : <*> = raise back() }; 

6 p:Add <- 

7 widget self:Add (phone[AddScreen,DoAdd+DoBack](’Tonys Phone’,s,[bl,b2])) { 

8 notifier:Notifier = n; 

9 notify(addr:str) : <Add> = do { return self }; 

10 add():<Main> = do { 

11 name:str <- s.name; 

12 address:str <- s.address; 

13 void:str <- db.update(name,address) 

14 return m 

15 >; 

16 backO : <Main> = do { return m }; 

17 move(x: int ,y: int) : <Add> = do { return self } 

18 } 

19 return p 

20 > 


Fig. 17. The Add Widget 


the connection to the service provider; this is 
done in several steps as follows: 

val create_notifier:<Notifier> = do { 
n:Notifier <- notifier(PORT); 
void: bool <- n. connect; 

void:bool <- n.register (’tonyOwidget.org’) 
return n 

> 

The event handlers add and del must perform 
a transition to the appropriate screen (lines 8 
and 9). Notice that in each case the transi¬ 
tion is performed by a function that returns a 
command yielding a widget of the appropriate 
type. The arguments to the function allow in¬ 
formation (self, contacts.db and notif ier) 
to be shared between widgets. 

The notify handler (lines 10-14) checks 
whether the address of the contact that has 
come into range is in the receiver’s contacts 
database. If so then a transition to a notify 
screen is made otherwise the command yields 
self which is a null-transition. 

Finally, the move handler (lines 15-18) in¬ 
forms the notifier of the change of location 
and makes a null transition. 


Figure 16 shows the implementation of the 
Notify widget. Notice how the use of func¬ 
tions allows system states to share informa¬ 
tion by passing argument values (line 1). In 
addition, since widgets can reference them¬ 
selves (self in figure 15 for example) they can 
pass themselves as continuation arguments (m 
in figure 16) to allow the target state to make 
a back transition (line 9). 

Figure 17 uses the built-in addscreen op¬ 
eration (line 3) to create a display involving 
the current contents of the contacts database. 
An add screen supports two commands name 
and address and is an example of a domain 
specific external widget that must be realized 
in a platform specific way for each implemen¬ 
tation mapping. When the add event is gener¬ 
ated, the update command is used to change 
the state of the database and a transition is 
made to the main screen. 

6 Related Work 

As pointed out in [?] MDA approaches have 
been applied to a number of application ar¬ 
eas, for example health care systems [?], how- 



ever source models tend to focus on the static 
structure of a system and do not include de¬ 
tailed behaviour. MDA often produces code 
skeletons that must be edited after the PSMs 
are produced. Where multiple platforms are 
involved, this defeats the purpose since multi¬ 
ple implementations must be developed and 
maintained. The approach described in [?] 
uses a DSL based on process flows defined by 
the A-MUSE project which differs from the 
work described in this article in that widget- 
behaviour is expressed using a functional pro¬ 
gramming language which is simpler, more 
expressive than the A-MUSE DSL, and in¬ 
tegrates both structural and behavioural as¬ 
pects of a system. 

There are many candidates for PIM mod¬ 
elling languages for rapp such as [?,?,?,?]. 
Most of these approaches use UML class dia¬ 
grams to express the structure of an applica¬ 
tion and activity models, collaboration mod¬ 
els and statecharts to express the behaviour. 
Whilst these approaches can express any be¬ 
haviour there is evidence that behaviours can 
become complex [?] and that “ when a mod¬ 
eller finds two or more possible semantically 
equivalent options for modelling a system, he 
should pay special attention to the use of the 
constructs that are part of the components de¬ 
scribed in this work, e.g., reducing the total 
number of activities of the diagram if possi¬ 
ble.'’’’ Our view is that the use of functional ab¬ 
straction in conjunction with state-based be¬ 
haviour can significantly improve the expres¬ 
siveness of collaboration, activity, and state- 
machine models alone, and can form a precise 
foundation for many different model driven 
approaches. 

Mobile platforms have given rise to an in¬ 
terest in context-aware applications that re¬ 
act to events that arise due to changes in 
the state of the platform or its environment. 
Context aware applications have been stud¬ 
ied only recently and there are few propos¬ 
als for modelling notations, for example [?], 
where context is declared from a number of 
sources and triggers are used to inform the 


application of context changes. Another ex¬ 
ample is [?] where context aware applications 
are modelled in terms of different viewpoints: 
social, task and space and where model trans¬ 
formations are used to produce platform spe¬ 
cific models from the views. 

Because of the increasing need to mod¬ 
ularize the cross cutting context dependent 
behaviour, Context Oriented Programming 
(COP) [?] has been proposed. COP is a pro¬ 
gramming paradigm to enable the expression 
of context-dependent behaviour. There have 
been several implementations of COP lan¬ 
guages for Java [?,?,?], Objective-C [?], Lisp 
[?], and Smalltalk [?]. These approaches mod¬ 
ularize context-dependent behaviour within 
layers , normally either layer-in-class or class- 
in-layer. Layer-in-class supports this modu¬ 
larization inside the class it affects. Class-in¬ 
layer supports this modularization outside the 
class, being largely comparable to aspect def¬ 
initions. These languages are dependent on 
their intended platform and language, lead¬ 
ing to difficulty in porting when attempting 
multi-platform development. 

Given the rise of the target platforms 
(for example over 172 million smart phones 
shipped worldwide in 2009 [?]), there are 
likely to be multiple DSLs or UML profiles 
defined for this type of application. An MDA 
approach to context-aware applications is de¬ 
scribed in [?] involving platform independent 
models of different features of an application 
that are translated to produce platform spe¬ 
cific artifacts. However: how can any candi¬ 
date PIM language be evaluated and com¬ 
pared to others?; how can the behaviour be 
defined in a universal way? 

There are a number of systems that aim 
to deploy a single application across multiple 
mobile or web platforms. Approaches differ as 
described below: cross compilation of existing 
applications; a model driven approach using 
a UML-style modelling language; new domain 
specific programming languages. 

The system described in [?] has been de¬ 
signed to help make code bindings between 



the different platform-specific frameworks by 
translating Java . class files to multiple plat¬ 
forms including Objective-C and JavaScript. 
A similar approach is taken in XMLVM [?,?] 
where byte-code cross-compilation is per¬ 
formed using a tool chain. This tool chain cur¬ 
rently translates Java Class files and .Net ex¬ 
ecutables to XML documents, which then can 
be output to Java byte code/.NET CIL or to 
JavaScript and Objective-C. This tool chain 
was firstly used to cross compile Java appli¬ 
cations to AJAX applications [?], because of 
the lack of IDE support and difficulty in cre¬ 
ating an AJAX application. Further work to 
include Android to iPhone application cross- 
compilation, as described in [?]. 

The DIMAG Framework [?] was devel¬ 
oped for automatic multiple mobile plat¬ 
form application generation. This is accom¬ 
plished by creating a declarative definition 
language which is comprised of 3 distinct 
parts; firstly a language DIM AG-root, which 
provides references to the definitions for work- 
flow and user interface in the application; 
secondly the language State Chart extensi¬ 
ble Markup Language (SCXML) defines the 
workflow by the definitions of states, state 
transitions, and condition based actions; and 
finally DIMAG-UI language based on MyMo- 
bileWeb’s IDEAL language using CSS to con¬ 
trol the user interface. The main shortcomings 
of this method is that it relies on server-side 
code generation and download. 

A recent proposal for a DSL for mobile ap¬ 
plications [?] uses XText and Eclipse to imple¬ 
ment a DSL that uses code generation tech¬ 
niques to target mobile platforms. This DSL 
uses fixed GUI structures such as section 
whereas our language uses user-declared ex¬ 
ternal widgets that integrate with the type 
system. It is also not clear whether the DSL 
has a static type system and its semantics is 
not defined independently of a translation to 
a target platform. 

Mobl (http://www.mobl-lang.or g/) is a DSL 
that has been designed to support mobile 
application development and which targets 


JavaScript. It has many things in common 
with our language, however the mobl features 
for describing GUI components are fixed and 
the semantics is not defined independently of 
the target language. 

Links [?] is a DSL that has been designed to 
support web application development where 
the 3-tier architecture is supported by a sin¬ 
gle technology. Like Widget, Links supports 
higher-order functions and is statically typed 
with respect to events and messages. Unlike 
our language, Links has been designed as a 
complete language with supporting tools, and 
indicates a possible future direction for layer¬ 
ing a user language on Widget. 

Web applications could not store local data 
to the web browser until the development of 
HTML5 [?]. In May 2007, Google released a 
plug-in for the Firefox web browser, Google 
Gears 3 . This plug-in supports caching of web 
applications to allow offline use, and also the 
ability for a web application to store data in a 
local database. Whilst this increases the suit¬ 
ability of web-technology for cross-platform 
rapp systems, there are still limitations in 
terms of GUI widgets a systematic use of 
events and static typing. 

Since the arrival of HTML5 and WebKit, 
a number of open source and commercial 
cross-platform frameworks have been pro¬ 
posed such as the Appcelaterator 4 , Phone- 
Gap 5 and Rhomobile 6 . These frameworks use 
either JavaScript or Ruby and therefore run 
in a browser. Furthermore these applications 
can run offline and access the device’s full ca¬ 
pabilities; such as a GPS or camera; providing 
the same look and feel as a native application. 

Functional Reactive Programming (FRP) 
uses arrow combinators to embed discrete 
event processing into the functional language 
Haskell [?,?]. The FRP approach is similar to 
the mechanism for representing commands in 
Widget (in that it is monad-based) and could 

3 http://gears.google.com/ 

4 http://developer.appcelerator.com/ 

5 http://www.phonegap.com/ 

6 http://rhomobile.com/ 



be used as an alternative basis for rapp de¬ 
sign. However we feel that FRP is based on 
more abstract notions of time and events that 
would make the integration described in figure 
1 more complex. Widget has been designed in 
terms of a domain-analysis for rapp systems, 
and therefore reflects the rapp computational 
framework directly in terms of event handlers, 
state transitions and hierarchical interfaces. 

DSLs in other areas include [?] that concen¬ 
trates on the abstraction of web applications 
to lower the overall complexity of the appli¬ 
cation and boilerplate code. Further work on 
this DSL led to the creation of Platform Inde¬ 
pendent Language (PIL) [?]. PIL was devel¬ 
oped as an intermediate language, to provide 
a scalable method for developing for multi¬ 
ple platforms. A drawback of this method is 
currently it lacks support for mobile platform 
development. 

Other efforts for making mobile application 
development easier include Google Simple 7 , 
a BASIC dialect for creating Android appli¬ 
cations, and the Google App Inventor 8 which 
is based on Openblocks [?] and Kawa 9 . Par¬ 
ticularly Google App Inventor has vastly ab¬ 
stracted app development, but only supports 
development of Android applications. These 
approaches are similar to visual programming 
and offer a quick start for application devel¬ 
opment but offer limited support for sophisti¬ 
cated behaviour. 

Brenhs has proposed MDSD, a DSL for 
iPhone. The language is more specific to 
data centric applications. Following from that 
work, they have started the Applause project 
for developing DSL for iPhone, iPad and An¬ 
droid 10 , but this is still not fully developed. 

There are a number of formal approaches 
to model behaviour of event-driven systems 
including modal transition systems [?], petri- 
nets, and the pi-calculus. Whilst these sys¬ 
tems have good analysis properties, they do 

1 http: //code, google.com/p/simple / 

8 littp://appinventor.googlelabs.com/about/ 

9 littp://www.gnu.org/software/kawa/ 

10 http://code.google.eom/p/applause/ 


not integrate with the structural features of 
rapp models in the way that Widget does. 

In review, there are many proposals for 
both model-driven approaches and DSLs for 
rapp. Most approaches lack an implementa¬ 
tion independent semantics, are unable to 
check system properties, many are fixed in 
terms of rapp features, and some offer limited 
features for expressing behaviour. 

7 Conclusion 

This article has described a rise in the inter¬ 
est in rapps due to the explosion of mobile, 
tablet and web-applications. The complexity 
and proliferation of implementation technolo¬ 
gies makes it attractive to use model-driven 
techniques to develop such systems. As de¬ 
scribed in [?] there are a number of challenges 
that makes mobile application software en¬ 
gineering challenging. These include develop¬ 
ment tools including testing, and portability. 
Our claim is that rapp models and Widget are 
a contribution to these challenges. In partic¬ 
ular, the formal definition of Widget provides 
scope for tool support and analysis. A VM im¬ 
plementation for Widget could be a basis of 
a write once run anywhere approach with the 
associated benefits to application verification. 

The Widget calculus was initially described 
in [?] and has been implemented as a type 
checker and language interpreter in Java. The 
current version of the source code 11 includes 
the Buddy application and uses a collection of 
general purpose external widgets and a phone 
simulator all written in Swing. Our next step 
is to provide a collection of external widgets 
using HTML and Android to show that the 
same Widget application can run on more 
than one platform. In addition, we plan to de¬ 
velop tooling around the rapp modelling lan¬ 
guage that can use the Widget calculus as a 
target. 


11 Available from http://www.eis.mdx.ac.uk/ 
staffpages/tonyclark/Software/widget_v_l_0. 
zip 



